查看原文
其他

【年会刚过,你中奖了吗?】在线抽奖活动中如何实现中奖概率的自适应调整

stephen 大数据与人工智能 2019-10-31


导读


笔者介绍

本人博士就读于武汉华中科技大学自动化学院(求东二楼、南一楼的小伙伴支持一下),毕业后从事大数据算法相关工作,和大家交流一点工作中的拙见!第一次写公众号文章,还请各位走过路过的仁兄爱护!

P.S. 本文中的算法,已经申请专利并获批,转载须经授权。


正题


记得刚开始工作的第一年,那是一个炎热的夏天,刚毕业的我去了一家互联网视频公司,在大数据部门实习。实习期间,部门老大考虑让我迅速了解公司业务,最开始就是和公司运营部门建立业务关联。故事从此拉开序幕,运营的小姐姐们为了促进用户活跃,绞尽脑汁地在APP上做在线抽奖活动,吸引更多的用户参与!


每次抽奖活动启动之前,部门老大都要被运营的同事叫去,给每种奖项计算一个中奖概率( 其实就是拍脑袋决定,但他们就是更迷信大数据的所谓数学“高材生”,貌似大数据部门的脑袋拍得比较准一点)。然后在活动期间,留一个运营小姐姐盯着中奖情况,根据用户中奖情况把中奖概率调高调低(十一长假啊,大家都出去玩儿了,这位小姐姐要一直盯着中奖情况,也太特么不人道了)。

后来我老大被搞烦了,就让我去算。每次活动都算,我也被搞烦了,于是就写了本文中的自适应概率模型,根据这个模型,后面所有的抽奖活动只需要进行简单设置就行了。本文将对这一模型进行详细介绍,并附有测试案例及结果分析,希望能给大家一些启发,权做抛砖引玉。

P.S. 后来正式入职。在接下来的年会抽奖活动上,先后中了一台全自动洗衣机和一套DW的手表+手镯。以至于,那些没中奖的小伙伴都怀疑我在抽奖代码里留了后门。

                  

主菜来了,下面来给大家介绍一下抽奖活动中的概率自适应调整,可能需要阅读两遍,估计一共需要花5分钟!


应用场景


无论运营还是技术,1年当中绝对不会少于1次抽奖活动,迷恋小概率事件是消费者行为学中最普遍被研究放大的,你产品的DAU(日活跃用户数)越大,抽奖概率的设置直接影响了用户体验。除了线上的抽奖活动,线下抽奖活动也会遇到很多,这个模型可以帮助你更好地自动调整中奖概率(当然,如果是一个小型的线下抽奖活动,比如几百人的公司年会,这样的概率模型当然不是必须的)。


开始活动之前有几个问题你一定会思考?

1、如何满足人类从众心理,让活动有一个火爆的开始并很快会有用户中奖?

2、如何让奖品被抽中的数量可控,想让用户中多少就中多少?

3、如何让奖品尽量均匀的在活动期间被抽完?别一上来就全部抽完了,后面没的玩,也别老是中不到奖堆积到最后。

4、如何防止刷奖,奖品一天很快就被抽完,后面的用户都抽不到?

5、如何让整个抽奖活动简单可配置,傻瓜式的只需要填上活动开始和结束时间,各种奖品及其具体数量即可?

概率模型


硬菜上线,看看下文的概率模型是否有帮到你(看到一堆参数,别害怕,简单解释一下即可玩转概率)。

     

     

图 1、中奖概率自适应调整公式

公众号回复「公式」下载高清公式图

注:所有奖项均采用该模型,但分别计算中奖概率,即每一种奖项都有一个当前的中奖概率。因此可根据实际需要,实现对不同奖项的分别定制概率。下面以一等奖为例,进行说明:

参数意义

NP:用户活动中的有效抽奖次数(有效抽奖:如果不允许一个用户多次中奖,则同一个用户抽完奖没中,下次为有效抽奖,中过之后再抽奖均为无效抽奖;否则,每次均为有效抽奖),该参数的设置不必精确(模型会即时调整,测试案例中说明),甚至直接使用默认值1000

numRemain:一等奖目前剩余数量

numTotal:一等奖总数量

timeRemain:截止到一等奖抽奖结束,剩余的时间

timeTotal:一等奖从开始到结束,总时间

step:概率调整的步长(解释一下)

offSet:偏置率(活动最后阶段,参加人数会非常少。在保证整个抽奖活动中奖事件按时间成均匀分布的基础上,确保奖品会被抽完)

测试案例


案例一、人数预估过量

(预计40000次有效抽奖,实际为34565)


参数设置讲解:

// 抽奖活动起止时间设置

val startTime = "2016-09-21 13:00:00"  

// 活动2016年9月21号,下午1点开始

val endTime = "2016-09-21 14:00:00"  

// 活动2016年9月21号,下午2点结束


// 有效抽奖次数估计

val NP = 40000

// 预估有40000次有效抽奖


// 奖品数量设置

val n0_total = 2                                                   

// 特等奖2个

val n1_total = 10

// 一等奖10个

val n2_total = 60 

// 二等奖60个

val n3_total = 200

// 三等奖200个

结果分析

1中奖情况

中奖情况如下图2所示,横坐标为时间(分钟),纵坐标为奖项(0:特等奖,1:一等奖,2:二等奖,3:三等奖)。结论如下:

1.总体来看,中奖按时间呈现均匀分布

2.58分钟,所有奖品抽完(offSet = 0.1,最后6分钟为活动结尾阶段)

3.人数预估过大,导致初始概率较小,开始阶段中奖人数偏少

     

图 2、案例一的中奖情况

2概率变化情况

     


分析

1)特等奖只有2个,因此中奖概率明显分成了3段。

2)总奖品有272个,第189个被抽出来奖品为第1个特等奖。

3)因为人数预估偏多,在第1个特等奖被抽出来之前,随着抽奖的进行,特等奖中奖概率缓慢上升。

4)在第1个特等奖被出来之后,特等奖中奖概率瞬间降低,然后缓慢上升,直至第2个特等奖被抽出来。

5)第2个特等奖被抽出来之后(第206个),特等奖已抽完,中奖概率为0。

6)一等奖、二等奖、三等奖的概率呈现同样的规律。


案例二、人数预估不足

(预计30000次有效抽奖,实际为101450)

参数设置讲解:

// 抽奖活动起止时间设置

val startTime = "2016-09-21 9:00:00"  

// 活动2016年9月21号,上午9点开始

val endTime = "2016-09-21 12:00:00"  

// 活动2016年9月21号,中午12点结束


// 有效抽奖次数估计

val NP = 30000

// 预估有30000次有效抽奖


// 奖品数量设置

val n0_total = 2                                                   

// 特等奖2个

val n1_total = 10

// 一等奖10个

val n2_total = 60 

// 二等奖60个

val n3_total = 200

// 三等奖200个

结果分析

1中奖情况

如下图3所示,横坐标为时间(分钟),纵坐标为奖项(0:特等奖,1:一等奖,2:二等奖,3:三等奖)。结论如下:

1.总体来看,中奖按时间呈现均匀分布

2.156分钟,所有奖品抽完(offSet = 0.1,最后18分钟为活动结尾阶段)

3.人数预估过少,导致初始概率较大,开始阶段中奖人数偏多


     

图 3、案例二的中奖结果

2概率变化情况



     

分析

1)特等奖只有2个,因此中奖概率明显分成了3段。

2)总奖品有272个,第52个被抽出来奖品为第1个特等奖。

3)因为人数预估偏多,在第1个特等奖被抽出来之前,随着抽奖的进行,特等奖中奖概率缓慢上升。

4) 在第1个特等奖被出来之后,特等奖中奖概率瞬间降低,然后缓慢上升,直至第2个特等奖被抽出来。

5)第2个特等奖被抽出来之后(第183个),特等奖已抽完,中奖概率为0。

6)一等奖只有10个,数量较少,因此呈现出与一等奖类似的规律。

7)二等奖和三等奖较多,前期因为人数预估不足,中奖概率一直在下降,直至低于应有的平均值。到活动中期概率,中奖概率在波动的基础上提升。最后阶段,概率波动变化,以保证所有奖品被抽完。

实战效果


1.本模型已经在公司的各种线上抽奖活动中运行多次,均很好地实现了预定目标,且不再需要人力调整中奖概率

2.通过中奖概率的自适应变化,可以实现中奖事件总体上按时间呈现为均匀分布

3.对预估的活动参与人数具有鲁棒性,可以有效应对预估不准的情况

4.抽奖活动的启动,只需要进行简单的设置

5.不同奖项中奖概率使用同一个模型,但分开计算,因此可以实现不同奖项的个性化定制(比如,让特等奖在某个时间点前抽完)


Happy Ending

本项目上线之后,当初的那个运营小姐姐多次找我问模型参数,一来二去,再来再去,后来。。。。哈哈哈,你没猜错。。。。就再也找不到借口来找我,也再没跟我讲过话了(可能是从来没出过bug吧)。。。。我终于过上了跟兄弟们“结对编程”,“快乐搞”的幸福生活。。。。。


更多精彩内容

长按扫码可关注



    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存